The present disclosure relates to diagnostic and customer-service systems for users of office equipment, such as copiers, printers, facsimile, and multifunction devices.
Office equipment, such as printers or copiers, typically uses a software-based operating system to perform essential machine functions and implement the various jobs of which the machine is capable. However, software, particularly that used in high-speed multifunction machines, is subject to various problems and faults. Additional problems also arise with the machine hardware which, in machines of this type, is extremely complex and sophisticated. Hardware and software problems that occur typically happen at a low, non-periodic rate and thus are very difficult to replicate when servicing the machine and therefore difficult to resolve. Further, many of these problems are identified by the customer, who is typically not technically trained to diagnose and service machines of this type. For this reason, it is important for a servicing organization to be able to access key machine operating information, and particularly information reflecting on the performance of the machine control system and physical states of machine componentry.
A common feature of the business arrangement between the user of the equipment and the supplier is that the user is responsible, at least in part, for some maintenance and basic trouble-shooting of the equipment. Often the equipment has componentry that can be tested, manipulated and perhaps replaced by the user, but in view of the investment in the equipment, users are reluctant to engage in system repair without the strong support of the supplier and its service departments. Accordingly, enhancing the accuracy and efficiency of equipment service is based on particularly articulating or determining equipment status and the occurring problem to a remote trouble-shooting service department. Frustrating experiences with the telephone communication-to-tech support departments is universally known and the problems with unsophisticated customers trying to actually communicate a problem to the department are extremely common.
Typically, when a user encounters a problem with a machine and cannot resolve it (or does not want to solve it himself), he (or a user representative) calls a support organization for assistance; such organizations typically have troubleshooters available to help. After salient details such as the machine serial number have been taken, the troubleshooter tries to ascertain the character and extent of the problem. When the nature of the problem and its possible causes have been uncovered, the troubleshooter will either propose some ways to attempt to resolve the problem or decide at this point that the call is best passed to higher level support. Where the troubleshooter attempts to get the user to resolve the problem, aside from his own knowledge and experience he may make use of a range of resources, such as an online knowledge base, physical machines, or the advice of colleagues.
The interactions between a user experiencing a problem with a machine and a troubleshooter on the phone recurrently involve a number of phenomena. The user and the troubleshooter between them build up a description of the problem that enables consideration of what an appropriate solution might be. This can include:
the provision by the user of an initial problem description, often containing a range of contextual information about the situation the problem has arisen in;
the reformulation of this description by the troubleshooter, into terms more specifically relevant to locating a solution;
affirmation/refinement of this description by the user;
potential further joint refinement of the problem/collation of other relevant features (either verbally or by getting the user to ‘go look’); and,
working together through instruction, implementation, and feedback to try out possible solutions.
In doing this work both the user and the troubleshooter routinely describe physical elements of the machine and give spatial directions or descriptions. It is often necessary to describe machine parts because users do not necessarily have the technical vocabulary to identify machine parts by name. The situation in which this particular problem with this particular machine arose has to be made available, where either party may only have partial information. The full extent of the problem also needs to be inquired into and made available. This may involve asking the user to undertake additional testing activities and report back. Potential solutions must be located and instructions given, followed, and their outcomes provided.
These interactions also typically take place under circumstances where the interactants only have access to an audio channel (telephone) which is not necessarily (physically) located by the machine, thereby requiring the user to negotiate a means of accessing the machine while retaining contact with the troubleshooter. The audio channel alone means that all descriptions, instructions and feedback are only verbal and the user will be the sole source of the initial problem description, circumstantial information, the results of the attempted instructions, etc. This can result in the troubleshooter requesting that the user repeat actions, either because they do not know the user has already done these, or because they cannot be sure the user has done these correctly. For the troubleshooter, where possible solutions come from textual resources, they will have to be digested from text and then articulated through purely verbal means. As a consequence of these circumstances a number of issues arise where the resolution is, at best, sub-optimal:
The user may lack access to the machine while on the phone and need to devote effort to coordinating access with others or constantly moving between the phone and the machine.
Troubleshooters will lack potentially significant and relevant information about the current machine status, the previous actions undertaken by the user, and the machine's previous behavior.
There is a lack of mutual access to the machine resulting in effort being devoted to:                describing the current state and answering questions in order to arrive at a mutually agreed expression of the problem;        producing instructions and directions and reporting back without being able to see how instructions and directions might be appropriately framed to the current circumstance (necessitating potentially redundant feedback and varying degrees of clarification); and        working out ways together to ensure that they are referring to the same physical components of the machine.        
Out of these observations it is possible to recognize two inter-related and potentially critical barriers to fully effective troubleshooting via conventional means:
1. The site of the problem is removed from the site of resolution for user-machine interactions. Excessive physical movement and coordination may be demanded, there is an absence of potentially important information to relevant parties, and both the problem and the resolution must always be mediated by verbal means.
2. The user-troubleshooter interaction is not best facilitated solely over the phone. Restriction to verbal mediation only diminishes the capacity to recognize the current state of the machine, the user situation, the object of reference, and the import of instructions.
The foregoing problems have suggested various needs for improved collaborative, distributed troubleshooting of network devices such as printers or MFDs (“multifunction devices”). There is a need for the improved communication of important information to be accomplished by the use of networking and user interface (“UI”) capabilities with the equipment to handle the collaboration between the user and troubleshooter, and to use sensors and actuators (LEDs in the equipment).
For printing devices that do not have rich user interfaces, fault clearance instructions or other device specific information is only available via documentation. Traditionally, this documentation has been printed or available electronically through web sites or other digital media. This documentation is typically static and in some cases can become out of date even before the device is publically available. Moreover, this documentation is typically not accessible when and where it is most needed at the device when there are issues.